You can disable the plugin using the tagging system by doing --exclude-tags=dirbuster

Is there a reason why adding a "none" tool option would be better? Your point about only running dirbuster against specific ports, or excluding ports is an interesting feature idea though.

Well, had I taken the time to read or understand the docs thoroughly I might have gotten that...

I was thinking about the plugin devs having the list upfront and making that a valid option.

It might be useful to allow a different dirbuster binary to be specified.

--dirbuster.tool='somesuper1337dirbtool -u %url% -o %output_file%'
That way you wouldn't have to write a plugin to support a new tool dirb tool.
Bit of a new set of params that are passed via those %something% vars.
I feel like that's feature creep, but as I'm thinking about that it feels useful.

I think it might require something of a community survey to collect "Top 10 useless http ports to dirbust on a pentest" so there'd be some community guidance about "useless/not useless".

Or not... It's your project. Pick whatever ports you want. Lol

I think adding a disabled-by-default --dirbuster.onlyports would be worth implementing. Then users could choose their own ports to include, e.g. --dirbuster.onlyports=80,443,8080,8443 etc.

As for writing a plugin to support a new tool, I have no issue with doing that, it's kinda the point of the plugin system, which replaced the config file based system in v1. Going back to passing full commands either via a config file or on the command line would be something I'd be against, since ideally you could easily just create a plugin.

Heck, you could create a plugin which matched all services and then ran commands based off a config file it loaded in if you wanted to.